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1.0 


INTRODUCTION 


1 . 1 Purpose 

The purpose of this document is to summarize the results 
of the Integrated Command, Control, Communications and 
Computation (IC*^) system study (contract NAS5-26369) . 

1 . 2 Scope 

The IC^" system study was awarded to Computer Technology 
Associates, Inc. in September, 1980. This study was conducted 
in the following three phases: 

a. functions] requirements phase 

b. functional architecture phase 

c. design plan phase. 

The results of the functional requirements phase were documented 
in Reference 2. The results of the functional architecture 
phase were documented in Reference 3. The results of the design 
plan phase were documented in the July 31, 1981 monthly status 
report (Reference 1) . This report provides a synopsis of the 
activities and results of the three study phases. 

1 . 3 Acronyms and Abbreviations 

CG&V Command Generation and Validation 

CRT Cathode Ray Tu >e 

D/L Downlink 

GSTDN Goddard Space Tracking Data Network 

H&S Health and Safety 

IC4 Integrated Command, Control, Communication, and 

Computation 

lOS Integrated Observatory Sequence 
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LRP 

Long Range Planning 

NEEDS 

NASA End-to-End Data System 

OBC 

On "Board Computer 

P&S 

Planning and Scheduling 

POI 

Period of Interest 

R/T 

Real-Time 

TDRSS 

Tracking and Data Relay Satellite System 

TM 

Telemetry 

U/L 

Uplink 
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2.0 APPLICABLE DOCUMENTS 

1. ic4 System Study Contract Monthly !R«ports 

2. IC^ System Functional Requirements. Computer Technology 
Associates^ Inc., March 31, 1981. 

3. IC^ System Functional Architecture. Computer Technology 
Associates, Inc., August 1981. 
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3.0 FUNCTIONAJ. REQUIREMENTS PHASE 


The purpose of ' <is section is to describe the functional 
requirements phase of the IC^ study. The results of the 
requirements study are documented in the IC^ System Functional 
Requiiuments document (Reference 2) . 

3 . 1 Functional Requirements Approach 

As shown in Figure 3.1’'! the generation of the requirements 
for the IC^ system first consisted of performing a survey 
of applicable documents and missions to determine a 
comprehensive set of command and control requirements. 

The requirements were then divided into natural groupings 
such that they could be analyzed from a top level 
perspective. (The outline given in section 3.4 of reference 
2 lists the requirements in the groups shown in Figure 3.1-1). 

The requirements were then analyzed by building a framework 
system around the groupings which allowed interrelationships 
to be studied. Figure 3.1-2 sun>njarizes the activities undertaken 
during this stage of the requirements analysis. 

3 . 2 Functional Requirements Results 

As shown in Figure 3.1-3 the results of the requirements 
gathering and analysis resulted in a complete set of functional 
requirements. It should be noted that these were generic 
requirements for a broad range of missions and were not 
specific to any mission; thus, mission unique items such as 
time of response or data volumes to be handled were 
not specified. Figure 3.1-4 illustrates the overview 
of the groupings studied during the requirements analysis. 

(Note; This overview wa&» modified during the architecture 
study as shown in Figure 4.2-1.) 
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DEFINE RESPONSIBILITIES 
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IC** FUNCTIONAL REQUIREMENTS - CONCLUDED 
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4 . 0 FUNCTIONAL ARCHITECTURE PHASE 


The purpose of this section is to provide a synopsis of the 
functional architecture phase of the IC^ system study. 

A description of the approach used to define the functional 
architecture is provided below. The results, as documented 
in Reference 3, are summarized \n subsequent sections. 

4 . 1 Approach 

To define the IC^ functional architecture, the following 
chree products were generated: 

a. functional hierarchy with allocation of functions 
to IC^ system elements 

b. operations concept with timelines of operational 
activities 

c. interfaces between the system elements. 

Figure 4.1-1 summarizes the overall approach to generation 
of the ic^ functional architecture. Requirements from Phase 1 
providi. d the basic inputs to this activity. The functional 
hierarchy and operations concept were derived based on these 
requirements. However, this process was iterative as the 
definition of operational activities and allocation of functions 
levied new requirements on the system. Once the functional 
hierarchy and operations concept were firm, system interfaces 
were defined. The result was then the functional architecture. 
This approach is defined in greater detail below. 

4.1.1 Functional Hierarchy 

The IC^ system was divided into the system elements illustrated 


9 


Figure 4.1-1 

GENERATION OF IC** FUNCTIONAL ARCHITECTURE 



by Figure 4.1-2. Each element was then decomposed into 
subsequent functions as shown in Figure 4.1-3. These 
functions included mission support, element control, data 
acquisition and utilization and ground control. Each system 
element performed various combinations of these functions as 
summarized in section 4.2.2 of this document. 

4.1.2 Operations Concept 

To define the ic4 operations concept, four operational 
activity threads were generated. Figure 4.1-4 summarizes 
the threads that were developed. These activity threads 
are defined in detail in section 4.2.4 of this document. 

4.1.3 Interfaces 

Figure 4.1-b summarizes the technique used to define the 
IC^ system interfaces. The chart was employed v’hich 
defines information generated by one element and used by 
another element. For example, in Figure 4.1-5 the number 
6A indicates that the science experimenter generates data 
that is utilized by mission management. Likewise, the 
number 6B implies that mission management provides 
information for the science experimenter element. The 
interfaces are defined in detail in section 4.2.5 to this 
document . 

4 . 2 Results 

The IC^ functional architecture is defined in detail in 
Reference 3. A synopsis of this document is given below. 
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The following aummary information to the functional architectur 
is provided: 

a. overview 

b. functional hierarchy 

c. key features 

d. activity threads 

e. interfaces. 

4.2.1 Overview 

Figure 4.2-1 provides an overview of the IC^ system. The 
components or system elements are indicated on the figure. 

The elements are summarized in section 4.2.2 to this document. 
Figure 4.2-2 summarizes the IC^ operational activities. These 
activities are divided into four phases: a) long-range 

planning, b) planning and scheduling for a period of interest, 
c) command generation and validation and d) real-time 
operations. These activities are summarized in section 


4.2,4 to this document. 



4.2.2 

Function Hierarchy 



Functional hierarchy charts are provided 

for the 

following 

system 

elements : 



a . 

science experimenter 



b. 

subsystem (power, thermal, data 

storage 

management) 

c . 

OBC (or command memory) 



d. 

subsystem (communicat ions) 



e . 

attitude subsystem 



f . 

orbit subsystem 



g- 

mission management 



h . 

observatory monitor and control 

• 



FUNCTIONAL ARCHITECTURE SYSTEM OVLKViEW 


7 



17 


• rTlTiiOF 
SLIBSYSTCM 


LONG RANGE PLANNING 




r — ^ 

PERIOD I 

Dae 


DO-OOO 


•PLANNING I SCHEDULI 



I 


IN-HOUSE 
USER R/T 
OPERATIO^ 


OlUOLNAL PAGF IP 

Sf poor quality 
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These charts are contained in Figures 4.2-3 through 4.2-lQ, 
respectively. It should be noted that for the purpose of 
siroplif icatior , several of the system elements have been 
combined as one. The functions of these elements are 
similar and can be so treated. Each of the elements are 
subdivided as outlined in section 4.1.1 and functions allocated 
accordingly. For a detailed description of the IC^ 
functional hierarchy refer to Reference 3. 

4.2.3 Key Features 

Four features are key to the IC^ system. These key features 
are as follows: 

a. interactive user 

b. sequence package 

c. adaptive update capability 

d. user in-house real-time operations capabilities. 

These features are summarized below. 

4. 2. 3. 1 Interactive User 

The IC^ system is designed to provide a common means for 
all users to access data within the system and to utilize 
facilities provided by the system. This common interface 
with the system is an interactive graphic terminal. As 
shown in Figure 4.2-11, the user terminal provides a means 
to interact with all phases of mission activities. Standard 
display formats are used which provide the mechanism for 
users to display data and enter data. The system provides 
skeletons or templates which provide starting points for data 
entry and a common framework within which all similar data 
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is contained. Users can customize the contents of a data 
package; however, as data packages and display packages 
are synonymous, the general format is always known 
to all users. The system provides the capability to merge 
data from multiple packages as one display for comparison 
purposes. Displays can also be updated to generate new 
displays going back to the starting skeleton and starting 
from scratch. 

The system provides the user the capability to access all 
information in the system and to present data to processes 
within the system. Thus, if a user has prepared a data 
package for processing, the package can be submitted to the 
standard IC^ procedures directly by the user. 

4. 2. 3. 2 Sequence Packages 

A prime example of the use of the interactive capabilities 
of the IC^ system is the sequence package. As described in 
Figure 4 2-12, the sequence package is the standard data 
package u jd to specify activities which are required to be 
done on-board the observatory. For each activity required 
of a science instrument or spacecraft subsystem, a sequence 
package is generated. (For identical activities which 
occur at varying times, multiple sequence packages are 
generated which specify the desired time of execution of the 
activity . ) 

Figure 4.2-13 illustrates a portion of the graphical 
representation of a sequence package as it would be seen upon 
a terminal. A user fills in data such as the examples 

shown in this figure. For some items, such as the event 
timelines, a low granularity version (major events) and a 
higher granularity version (detailed events) actually 
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are the same data. The user or other users can select the 
timeline and specify which granularity they wish to have 
displayed. Similary/ during early planning times, coarse 
granularity is all that is required; however, in order to 
generate the actual command load a detailed, completely 
specified timeline is necessary. Figures 4.2-14 and 4.2-15 
illustrate the tabular version of the sequence package. 

The originator may choose to enter the data in a graphic 
or tabular form, and the system services will convert either 
form to the alternate presentation upon command. When a 
sequence package is completed it supplies all data necessary 
to generate a command file for uplink to the observatory 
and to perform a command generation and validation test. 

4. 2. 3. 3 Adaptive Update Capability 

Figure 4.2-16 summarizes the types of adaptive updates that 
IC^ system users may implement. Also, shown is the impact 
to the observatory sequence. Figure 4.2-17 summarizes the 
time periods during which users may institute these commands. 
Refer to Reference 3 for a detailed description of the user 
adaptive update capability. 

4. 2. 3. 4 User In-House Real-Time Operations Capabilities 

Figure 4.2-18 summarizes the real-time operations capabilities 
provided to each user. These capabilities are defined in 
detail in Reference 3. 

4.2.4 Op erations Activity Threads 

The following activity threads are provided below: 

a. long range planning 

b. planning and scheduling 

c. command generation and validation 

d. real-time operations 
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FIGURE 4.2 14: Contents of a Sequence Package, Part II - Graphics ( 1 of 2) 
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INTERACTIVE TERMINAL 



4.2.4. 1 Long Range Planning 


Figure 4.2-19 summarizei the long range planning activities. 
Refer to reference 3 for a detailed description of long 
range planning. 

4. 2. 4. 2 Planning and Scheduling 

Figure 4.2-20 summarizes the planning and scheduling 
activities for the planning period of Interest. Figure 
4.2-21 Illustrates the capability to modify the observatory 
sequences once they have been generated. These activities 
are defined In Reference 3. 

4.2.4. 3 Command Generation and Validation 

The command generation and validation activity thread and 
the thread to implement parameter updates are summarized 
in Figures 4.2-22 and 4.2-23, respectively. The detailed 
activities are d^-fined in Reference 3. 

4 . 2 . 4 . 4 Real-Time Operation 

The real-time operation for both locaJ operations and in-house 
user operations are summarized in Figure 4.2-24. The 
detailed activities are defined in Reference 3. 

4.2.5 Interfaces 

Figure 4.2-25 summarizes the interfaces for the IC^ system. 

For each number indicated, detailed interface 
descriptions were generated. Table 4.2-1 is an example 
of an interface description, in this case a portion of 



1 


number 6A (science experimenter to mission management) . 
Reference 3 contains the detailed description for all of 
these Interfaces. 
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Request to activate Mi3sii)n Manageim 
to generate "potential” oLservatory 
sequence using modified seq.ience re 


5.0 DESIGN PLAN PHASE 


The IC^ system design plan was defined in the July status 
report (Reference 1) . This section provides a synopsis 
of the IC^ system design plan. 

The effort to design the IC^ system detailing hardware and 
software components and personnel activities will be conducted 
in two phases. Phase 1 will define and design a basis IC^ 
system which is a ^jironand and control system that is common 
for all GSFC missions. The basis IC^ system then becomes 
a standard and precanned set of capabilities, functions, 
hardware and software that can be used by multiple mission 
disciplines. During Phase 1 the basis IC^ system will be 
defined and the design of the detailed personnel activities, 
software modules and hardware components will be accomplished. 
Architecture design trades will be performed as necessary 
to affect the system design. Inherent in the IC^ functional 
architecture are mission unique capabilities that are not 
applicable for all missions, and these functions are not 
part of the basis IC^ system. Phase 2 will demonstrate 
the manner by which a complete IC^ system is defined based 
upon a hypothetical mission model. During Phase 2, a 
hypothetical mission which will include selected mission 
unique capabilities that have been excluded from the 
basis ic4 system will be defined. A total IC^ system 
will then be designed illustrating deltas to the basis 
system necessary to accommodate the hypothetical mission 
case . 

Phase 1 is divided into two subtasks of activity. Subtask 1 
will address the functional definition of the oasis IC4 system 
and will depict the mission unique capabilities that are not 


included in the basis system. Subtask 2 will be the detailed 
design of the basis IC^ system. 

Phase 2 is divided into two subtasks of activity. Subtask 1 
will include detailed definition of the hypothetical mission. 
Subtask 2 will show the expansion of the basis IC^ system 
design to encompass the hypothetical mission. 
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